It was three weeks ago now that I wrote about Lessons in website security anti-patterns by Tesco where I pointed out a whole raft of basic, flawed practices which jeopardised the security and privacy of shoppers. These practices in and of themselves were (are) bad, but what really seemed to fire up a lot of people was Tesco’s response when I first flagged it with them:
1,883 retweets later, numerous media articles and a chorus of software and security professionals decrying Tesco’s approach to security (and customer service, for that matter) including one of the industry’s most preeminent security brains referring to their password security as “lousy”, and nothing has changed. One of the things that hasn’t changed is their continued assertion that there’s nothing to see here – no security problems, move along now“
This was just last week and well after the “robust” theory had been well and truly rejected by a great number of people who actually know what robust security looks like (or least know what it doesn't look like). Of course this same canned response was used many, many times to people raising legitimate concerns so I’m sure it’s nothing against Craig in particular.
But Tesco have security problems that go beyond what I originally wrote about, far beyond. At the time, I speculated that this was reminiscent of the Billabong situation where there were numerous bad security practices easily observable in addition to the ones which allowed an attacker to steal 21,000 account details. So it was no surprise when people started commenting about additional vulnerabilities such as SQL injection (unverified) or personally emailing me details of risks such as cross site scripting (verified). It was also no surprise to hear that many people had raised security concerns with Tesco over many years but to no avail. After all, they’d “never been hacked” (their quote) so things must be robust, right?
Let me get to the point of this post; I had someone from Tesco connect with me privately after which I asked for some technical contacts I could pass on information to. I’m not going to publicly divulge any names or positions publicly, but what I can say is that I was given the details of multiple people in senior technology roles after which I then passed on (anonymised) details of the cross site scripting (XSS) risk that was sent to me. That was two and a half weeks ago so nearly a week later, after receiving no response, I followed up on the original message. Nothing. Nada. Zip. And the vulnerability is still there.
What you need to know about XSS
At this point I want to stop talking about Tesco specifically and turn this around to a more constructive post; things you need to know about XSS. I’m going to approach this a little differently and provide a video as it requires a bit of social engineering which is best illustrated in real time. A number of the risks you see in this video are present on Tesco’s website but equally, some of them are not. Clearly I’m not going to disclose any detail which will allow someone to go off and get involved in malicious activity, but what I am going to do is show how XSS can be used to cause serious trouble and that’s what I hope Tesco (and others) can begin to appreciate.
Just on the browser compatibly for that XSS: IE9 and IE10 are actually pretty good and will warn you about it without exexuting it. All other browsers tested – Chrome, Firefox and Safari (desktop and iOS) – will happily parse it and allow the exploit to occur.
Summary
As I said earlier, not all the risks I’ve highlighted in the video may be present on Tesco’s website and I’ve intentionally avoided reproducing the specific circumstances where they are vulnerable. Some would argue that sufficient time has passed since responsible disclosure to publish details, but I don’t think that is necessary regardless of how frivolous Tesco believe the risk is. But certainly there are enough of these risks to be very concerned though, definitely more concerned than leaving it unfixed for days let alone weeks.
Interestingly, it seems that Tesco’s rather unique approach to security is now coming under scrutiny from the Information Commissioners Office in the UK. Whilst a statement such as "We are aware of this issue and will be making inquiries" is far from a damning indictment, it will be interesting to see how this unfolds and whether the company may actually be called on those “lousy” practices.
To wrap up on the general XSS discussion, there are really two key things which absolutely, positively have to happen but often don’t:
- All input must be validated against a whitelist of acceptable value ranges. In fact this is so important it appears in big, bold letters on my post about OWASP Top 10 for .NET developers part 2: Cross-Site Scripting (XSS)
-
All output must be encoded for the context in which it is emitted. HTML, HTML attributes, CSS, JavaScript, XML, XML attributes etc. Not getting the context correct or even worse, not encoding at all can be disastrous.
Other lax security practices can then be combined with XSS to make the site more readily exploitable; cookies which aren’t flagged as HTTP only, for example. Plus of course there’s good old social engineering to help exploit reflected XSS.
Then there’s the fact that in terms of web app vulnerabilities, XSS gets very, very messy. How? Well to begin with different browsers implement different levels of defence. For example IE10 protects against some of those earlier examples where latest gen Chrome and Firefox don’t. Then there’s the fact that XSS is only roughly related to semantically correct HTML; browsers frequently allow markup to be parsed which shouldn’t be, for example IE6 will happily parse a tag like <IMG SRC='vbscript:msgbox("XSS")'> which contains VB Script. The XSS Cheat Sheet will give you a sense of just how obscure things can get.
As always, we’re back to security in layers. One particular flaw may not appear too serious but combined with other risks, things can get very nasty very quickly. Mitigating XSS on the vast majority of websites is simple – I mean really simple, at least for things like whitelisting and output encoding. The website used in the video above was easily made insecure just as it is easily made secure and you download the whole thing from GitHub (including comments on how to secure it) from the resources below.
Resources
- The codebase for the “robust” site used in the video is publicly accessible over on GitHub under ShopWithRobustSecurity
- You can still see it in action at ShopWithRobustSecurity.apphb.com
- The site which was then used to harvest cookies and credentials is also on GitHub under EvilShopliftingSite
- WhiteHat Security’s report referring to XSS being the most prevalent risk is here
- Details on Samy’s MySpace XSS worm are on the SecurityFocus website